\chapter{Implementation}\label{cha:implementation}
In this chapter, the implementation of our peer-to-peer Wi-Fi sharing will
be discussed. 
Our implementation is based on the \emph{HIP for
Linux} (HIPL) implementation \cite{hipl}.   
In section \ref{sec:imp_overview} we give an overview of our
implementation. In section \ref{sec:imp_details} the
implementation details will be discussed. Section \ref{sec:imp_state} summarizes the
implementation work and discusses the future work for implementation.
\section{Overview of the Implementation}\label{sec:imp_overview}
Our implementation consists of four main parts. The authentication part,
the middlebox part, the tunneling part and helper programs.

The authentication part is integrated in the Base Exchange and Update
process. It plays together with the middlebox program to
fulfill the task of authentication.

The middlebox program participates in the authentication process.   
It makes sure that the home router is a valid member of
the community, and it is willing to forward the mobile user's traffic
to the 
Internet. It also checks whether the communication peers are authentic.

The tunneling program is responsible to forward the traffic of the mobile
user to the home router and for the  
Internet and vice versa. It uses the Linux TUN/TAP device
for IP tunneling. The tunneling program can be used both for the
standard mode and the optimized mode as described in section
\ref{sec:design_opt}.

Besides the main parts, we also implemented helper programs to handle
certificates and tokens as described in section \ref{sec:design_pcert} and \ref{sec:chain}.
To proof the concept, we also implemented a prototype of the logging 
program which is 
described in section \ref{sec:logging}.

Another platform for our implementation is the normal home router
which is capable of running OpenWrt \cite{openwrt}, a Linux distribution for embedded
devices, especially wireless routers. Thus our implementation will also be
cross-compiled to the MIPS/MIPSEL-platform.

\section{Implementation Details}\label{sec:imp_details}
\subsection{Modification of HIP daemon for Authentication}
The HIP daemon is the core of the HIPL implementation. With the support of
HIP-patched IPsec BEET mode kernel module, the HIP daemon is implemented as
a userspace program. The HIP daemon handles all kinds of
activities of HIP like the HIP state machine handling as defined in
\cite{hip_draft}, packet generation and handling, security related
operation like signing the packet and verifying the signature, creating and managing
SAs etc. 

In our implementation, the authentication part covers mainly the packet
generation and handling. The most functions related to packet generation
and handling are located in the \texttt{input.c} and \texttt{output.c}
files. For sending the I1 packet, we added a function to add the Wi-Fi
flag. For the R1 handling function, we implemented codes to process the Wi-Fi
flag. Nonces from the middlebox must be processed and put in the signed area
of the packet. For the R1 handling function, we added codes to solve the
puzzle from the middlebox and to sign the nonce. Originally, the Host ID was
encrypted in the I2 packet, since the middlebox needs the Host ID to verify
the signature and it does not have the shared key, the encryption was
removed in our implementation. We also added codes to include the optional
token. In the I2 handling function, we added codes to verify the token.

The functions for sending/receiving and processing the Update messages are
located in the file \texttt{update.c} and must
also be modified and extended. Besides the codes for inserting the
certificate and verifying the signature, the Host ID must be included in
the Update messages so that it can be used by the middlebox to verify the
signatures. 
\subsection{Traffic Control on the Middlebox}
The program for traffic control on the middlebox is the main part of our
implementation. It takes part in the Base Exchange and Update process,
verifies the certificate, adds puzzle and nonces and verifies the
signature. Additionally, the ESP traffic is also filtered by the middlebox
program.

There is  a prototype design and implementation of HIP enabled
firewall \cite{da:hip_firewall}. However this firewall implementation is
optimized for IPv6 and supports partly the public available IPv4-networks. 
The HIP firewall only filters the HIP traffic and ESP traffic based on the
pre-defined firewall rules and does not modify the content of the HIP
control packet. In our implementation, we mainly handle the
UDP-encapsulated HIP and ESP packets, which are not supported by the HIP
firewall implementation. Thus, 
a new implementation of the middlebox program
from scratch is needed.

We use the Netfilter QUEUE target to put the related packets from the
kernel to the user
space. The packets will be processed by our userspace program and sent back
to the kernel TCP/IP stack.

We implemented the traffic control program  with the
library \texttt{libipq}. 
Libipq is a
userspace library that uses Netlink to communicate with the Netfilter
modules of Linux kernel. 
All traffic which is directed to the QUEUE target through iptables rules
can be handled by a program which uses libipq.

We firstly implemented library functions to handle the UDP-encapsulated HIP
and ESP packet. These functions include getting IP header, UDP header from a
libipq packet, recognising the type of the HIP packet from a libipq packet
etc. Then the functions to filter each type of the HIP control packet and
the ESP traffic are implemented. In the main function, we detect the type
the packet and process them using the functions we defined.
\subsection{The Tunneling Program}

Since the tunneling in our implementation uses the scheme of \emph{IPv4 in
IPv6 and then from IPv6 to IPv4}, a tunneling program must at least support
IPv4  in IPv6 tunneling. The most available free tunneling programs like
OpenVPN \cite{openvpn} or VTUN \cite{vtun} do not support IPv6. In addition, since security and user
authentication have been solved by HIP, we only need a simple tunneling
program without encryption and user authentication. Thus we decide to
implement our own tunneling program from scratch rather than to extend the
available tunneling programs like OpenVPN with IPv6 support.


The tunneling program consists of a server part and a client part. In both
parts of the program, HIT of the communication peer is used as destination
address and the own HIT is used as the source address. Normal IPv4 packet
from the TUN device is packed as payload into an IPv6 UDP packet. The IP header of 
the new IPv6 UDP packet
will be replaced by the IPsec BEET
mode kernel module 
with a IPv4 IP header before it leaves the client host. The mapping between
the HIT and IP address is gained from the Base Exchange and the Update
process. On receiving the IPv4 UDP packet, the server part of the program
will reverse the operations described above and then send the IPv4 packet in the payload to its
destination.

We implemented the tunneling program over UDP instead of over TCP. The
tunneling over UDP provides a higher performance and the reliability is
provided by the TCP connections between the application server and the
mobile client. 
We used the \texttt{select} function to multiplex and demultiplex the
traffic from the TUN device and the UDP socket. Since in Unix
``everything is a file'', it is very convenient to get packets from the TUN
device using \texttt{read} and to put the packets to it by using the
\texttt{write} function.

Because the implementation of the IP datagram fragmentation is not
mandatory in IPv6 and the minimal MTU of an IPv6 packet is 1280, we 
reduced the MTU of the TUN device to 1100 Bytes so that packets from the TUN
device can be packed in the payload of the IPv6 UDP packet.

On the server side, IP-forward must be enabled and the IP masquerade must
be set by Iptables rules.
\subsection{Helper Programs}
We also implemented some helper programs to create, save,  load and verify
the community 
certificates and tokens as described in section \ref{sec:design_pcert}.
Furthermore, we also implemented a prototype of the logging
program to proof the concept. It also uses the userspace library
\texttt{libipq} to recorded the activities of a user in the hashed form. 
\section{State of the Implementation}\label{sec:imp_state}
Our approach for Wi-Fi sharing delegates HIP to solve the problem of
security and other features like mobility. The way that we build a tunnel
to the home router and through which to the Internet solves the problem of
Wi-Fi liability. 

The modification and extension of the HIP daemon were done successfully.
A middlebox program is written from scratch to take part in
the BEX and the Update process, and to filter the ESP packets. The tunneling
program and route
setting script are also implemented. 


The most time was spent to implement the middlebox program, because we must
handle the UDP-encapsulated HIP control packets and ESP traffics. 
Additionally, during our
implementation, some bugs of HIPL were found and to fix them has taken a lot
of time. 

Due to limited time for the thesis, our implementation is still not stable
enough. Thus the code should be maintained and more debugs should be made.

Although the mobility works generally, even for the client host in a NATted
environment, we have not managed to bring the mobility of the tunneling to
work. The reason lies in the fact that the HIP daemon does not handle the
Netlink message of the TUN-devices in a right way, so that the SAs 
cannot be
updated correctly.

For the optimized mode, the authentication process is not implemented. The
logging program was implemented separately to proof the concept and 
should be integrated in 
the optimized mode. The
tunneling problem can be used for this mode, however, it is still quite
primitive, features like automatic route setting etc. should be
adapted in the future work.
